The invention relates to a method for operating a multicore processor system, by means of which different threads (program parts or program paths) of a program are executed by a plurality of processor cores of the multicore processor system at the same time, each processor core executing a different one of the threads. The invention also includes a multicore processor system having a debugging device for analyzing the program. Finally, the invention also includes a computer program product which can be used to enhance a conventional multicore processor system in the sense of the method according to the invention.
In order to provide so-called “true” multitasking, a computer may comprise a plurality of processors or else one processor having more than one processor core. Such an arrangement comprising a plurality of processors and/or a plurality of processor cores inside a processor is referred to as a multicore processor system here. Such a multicore processor system is used to execute individual program parts (threads), which can be executed independently of one another, in a truly parallel manner, that is to say at the same time. Programs which internally consist of a plurality of threads can be distributed among virtually any desired number of such processor cores, with the result that more than only one thread is always active.
However, many such programs constructed in this manner have hitherto often been executed only on so-called single-core processor systems. Only pseudo-multitasking can be provided by a single-core processor system. In this case, the individual threads of a program are executed in rapid alternation in succession, with the result that there is no true temporal parallelism. If such a program is now executed on a multicore processor system, this may result in completely new error patterns if the program is not correctly structured at all points for a multicore processor system.
Error searching is called debugging (error=bug). The structure of a debugger generally consists of two parts: the frontend, which provides the programmer with various possibilities for controlling error analysis, and the backend, which then looks after the execution of these control commands while the frontend continues without being influenced. These two units (frontend and backend) are themselves programs and can also run on computers other than the multicore processor system, which is widespread, in particular, in the field of embedded systems.
So-called debug probes are an additional possible form of implementation of a backend unit. This hardware circuit processes debug commands or debug instructions from the frontend and forwards them to the multicore processor system via special hardware debug interfaces. An example of such a debugging system emerges from the JTAG standard (Joint Test Action Group, IEEE standard 1149.1). In this case, the processor cores can be individually addressed in multicore processor systems.
Debugging generally provides two important mechanisms which stop a running program, that is to say interrupt the execution of the program on a processor core. The program is either stopped from the outside or a breakpoint was previously set in the program code of the program, which breakpoint stops the program when the program counter of the relevant processor core reaches this point irrespective of the thread in which the program is currently situated. There are then substantially also two possibilities for how the program is continued. Either only an individual command in the current thread is executed (single step) and the processor is then interrupted again or the program is continued in full (continue command), which may again result in thread changes.
In single-core processor systems, the entire processor stops, that is to say the program per se is not executed any further, in the case of both interruption possibilities, thus ensuring that all threads and therefore all data in the program which describe the current program state are exactly in the state which is present when the one thread stops. In the case of continuation by means of a single-step command, only those program data which are changed by the current thread by means of the one program step likewise change.
All of this no longer applies to multicore processor systems, with the result that some problems arise in order to stop the program in a consistent state and in order to be able to draw reliable conclusions on possible causes of errors from the program data. This is because, if the threads of the program are distributed among a plurality of processor cores and the execution of a thread is then interrupted because the thread runs onto a breakpoint, only this one processor core also initially stops, while all other processor cores and therefore also the other threads of the program continue, that is to say are executed further by the other processor cores. In order to prevent continuation, a debugger must also stop the other processor cores after detecting a program interruption in one processor core. The following mechanism is used for this purpose. If a thread runs onto a breakpoint, exception handling is triggered in the processor core affected, that is to say a so-called exception handling routine is processed by the processor core affected. This routine reports the event to the backend of the debugger which in turn forwards the event to the frontend. The frontend has the corresponding information relating to the threads and the processor cores, with the result that it can likewise stop the processor cores on which the other threads of the same program are running by means of a command to the backend.
However, this process lasts for the order of magnitude of milliseconds, which may result in the program to be analyzed already being very much further in some threads than it was at the time of the interruption at the breakpoint in the one thread. Entirely different threads may likewise be active in the meantime and threads may even have ended. This applies, in particular, since modern processors have clock frequencies in the Gigahertz range, with the result that approximately 1 million commands are executed per millisecond. Therefore, no consistent indication of the program data in the program upon reaching a breakpoint can be established in this way. Furthermore, it is also unknown what is actually supposed to happen in a multicore processor system in the event of a single-step command. Does only the one thread which caused the interruption continue for one program step or are all threads which are currently active on the other processor cores likewise supposed to be executed further by one program step?